Subject: AIW 4 APPN Architecture Reference SIG minutes

From: "Ralph Case" <[email-masked]>
Date: Thu, 17 Mar 94 11:17:38 EST

MINUTES OF ARCHITECTURE REFERENCE SIG AT AIW4
_____________________________________________

  This SIG discusses clarifications, fixes, and minor
  enhancements to the APPN architecture.  The focus is on
  improving the quality and interoperability of APPN
  Implementations.

  The session was presented by members of IBM's APPN
  Architecture Team:  Ralph Case, Tim Hefel, Tom Moore, and
  Marcia Peters.  Thanks to Marcia for taking notes during
  the session.

  If we've missed something from the meeting, or if you
  have additional questions or comments, please post them
  here or send them directly to us.

ARCHITECTURE UPDATES

  This is a summary of key points raised during the SIG
  meeting.  These notes are intended to supplement the
  handouts in the AIW4 binder.

Correcting Distributed TDB when NN becomes an EN/LEN

  Normally, this is not a problem.  When a node changes, it
  brings its links down, preventing them from being used
  for intermediate routing.  A node could change without
  its partners knowing if the links are switched.

  All TGs from a former NN, including those to VRNs, must
  be made inconsistent.

  Every time a NN brings up a link to an EN, it must check
  the TDB for this scenario.

Limit of one TDU per Conversation

  Implementations must abide by this rule, but should not
  enforce it.

Strip NetID from RSCV

  For a hop across a connection network, there are two TG
  descriptors.  Both must be checked for NETIDs.  To
  determine the partner for the next hop, first check the
  NETID on the second TG descriptor.  If there is none,
  check the NETID on the first.  If there is none, assume
  the current node's NETID.

Don't Increment own RSN in Initial Topology Exchange

  This applies to either full or partial initial topology
  exchanges.

Negotiating FRSN with non-Safestoring NNs.

  The FRSNs being compared are the ones in the CP
  capabilities exchange.

Blank/Null Mode or COS

  If a default COS is provided by an operator, it may not
  be what's expected if a user assumes the default COS is
  #CONNECT.  Alternatively, if a user requests a specific
  COS that is not available, a default COS unacceptable to
  the user may be used.

  Implementations should carefully consider the
  implications of providing the product options discussed.
  For example, VTAM will issue an operator message when a
  default COS is used because a requested COS is
  unavailable.

Routes through VRNs

  If there is a pre-defined TG between two nodes on a SATF,
  sometimes, a route using the pre-defined TG will be
  chosen, and sometimes, a route using the VRN will be
  chosen.  If the route through the VRN is chosen, a new TG
  parallel to the pre-defined one is activated.  This
  requires support for parallel TGs over the LAN.  The
  newly activated TG must have a different SAP.

  It was suggested that CS could recognize this scenario
  (activation of a new link over a CN to a node where there
  is already an active link), and use the active link
  rather than the link specified in the RSCV.  This could
  create other problems by adding route selection
  responsibility to CS and reduce the ability of RSS to
  determine a specific route.

  Bridges on a LAN cannot be represented in routing weight
  tables.  This makes it difficult for APPN to select
  optimal routes through bridged LANs.  A solution is to
  replace bridges with Network Nodes.

  A concern was raised about the interaction between
  Connection Networks and Border Nodes.  Since Border Nodes
  isolate topology, using Border Nodes to separate subnets
  on a connection network eliminates some of the advantages
  of a connection network.  This is a limitation that will
  require future architecture to address.

ISR Handling of two-stage pacing

  Several clarifications were requested.  Tom Moore has
  already posted them here.

ASM Clarifications

  The LFSID Address Space table does not cover the case
  where the ODAI is 1 and SIDH is 00 or 01.  This case is
  reserved.  The table will be updated to show this.

  Question:  Does the adaptive BIND pacing indicator apply
  to dependent BINDs, independent BINDs, or both?

  It applies to both.  It is important to note that at
  intermediate nodes, ASM treats a BIND for a dependent
  LU-LU session as if it were for an independent LU-LU
  session.  That is, if a BIND for a dependent LU-LU
  session contains an RSCV and the value of the Current Hop
  Count field is less than the value of the Max Hop Count
  field, ASM need not even be aware that the session is
  between dependent LUs.  So at ISR nodes, adaptive BIND
  pacing obviously applies to both independent and
  dependent BINDs.

  A distinction between dependent BINDs and independent
  BINDs is made only at the Boundary Function-Secondary LU
  stage; that is, only in nodes that:

  1.  contain dependent secondary LUs OR

  2.  provide Boundary Function support for dependent
      secondary LUs located in an adjacent node.

  Since these nodes will distinguish between independent
  and dependent BINDs, the following clarification is
  provided:

  The BIND pacing support indicator in the XID3 was
  originally intended to apply to both dependent and
  independent BINDs.  Some products, however, were
  implemented such that they paced only independent BINDs.
  The "Qualifier for Adaptive Bind Pacing Support" was
  added to the XID3 to allow these products to interoperate
  with products that paced both.

  Products that pace only independent BINDs indicate such
  by setting the qualifier to '11'b (now a retired setting
  - i.e., new implementations will pace both independent
  and dependent BINDs).

  Current-level boxes (can pace both dependent and
  independent BINDs) set the qualifier to '01'b to indicate
  adaptive BIND pacing applies to both independent and
  dependent BINDs, unless overridden by the partner node.

  Back-level boxes which correctly pace both types of BIND
  are unaware of the qualifier for adaptive bind pacing, so
  the qualifier will be set to '00'b.  This indicates
  adaptive BIND pacing applies to both dependent and
  independent BINDs, and is nonnegotiable.

Interoperability with Border Nodes

  If there are several BNs connecting two subnets, multiple
  locate replies may occur.  This is not an error.  Just
  use the first one (subject to the issues discussed in
  "Search Result Preferences" below) and ignore subsequent
  replies.

  If multiple wildcard replies are received, problems could
  result.  The wildcard restriction should be extended to
  say that only one wildcard definition is allowed in a set
  of interconnected subnets.  Advise customers to not use
  wildcards at all.

Encoding MAC address in TG Descriptor

  This does not change the use of the address in a box or
  in presentation to users.  It only refers to the encoding
  in the '4682' subfield.

Parallel TGs over a LAN

  There was an outstanding question as to whether the
  DEFINE_LINK_STATION command should include the local or
  remote SAP address.  The DEFINE_PORT command should
  include the local MAC address.  (The Architecture
  reference implies it includes the local MAC and SAP.)
  The DEFINE_LINK_STATION command should include the local
  SAP and remote MAC and SAP.  This allows flexibility for
  parallel TGs even if the partner does not support
  multiple SAPs.

  Different products define different fields for entering
  MAC and SAP addresses.  This causes installation
  headaches.  Architecture could make a suggestion to
  standardize the presentation.

Search Result Preferences

  The tables are incomplete since a Border Node that looks
  like an End Node can return a wildcard.  This was
  discussed in "Interoperability with Border Nodes".

  APPN architecture ensures that a search always completes.
  If there is a bug in some implementation and it doesn't
  complete, it is up to the user (or application) to get
  impatient and cancel or retry.  If this problem does
  happen, the architecture does not provide much help in
  isolating it.

SIG PROCEDURES

  There was a discussion of how to get AIW members informed
  of architecture updates earlier.

  o   IBM will place changes on ibmstandards rather than
      just presenting them at conferences.

  o   An index file will be provided to track the list of
      changes.

  o   Any additions to the library will be publicized on
      the mailing list.

  o   Changes identified in this SIG must be communicated
      to the validation BOF to ensure that tests are
      developed to the latest level of architecture.

  There was a discussion of the importance of agreeing on
  and prioritizing items for this SIG.  Most of the items
  are in response to specific questions or customer
  situations that require architecture clarifications or
  fixes.  However, I would like to make this group as
  responsive as possible to your needs.  Please let us know
  what subjects you would like to see addressed by this
  SIG.

Ralph Case                    [email-masked]    (919)254-1882
APPN Architecture
IBM Networking Hardware Division

---

From: [email-masked] (Dave Finnie)
Date: Fri, 18 Mar 94 14:46:39 EST

Ralph,

Unfortunately I was unable to attend AIW 4, so I was not
able to participate in the architecture discussions at the

>  reserved.  The table will be updated to show this.

I don't recall any discussion that only the link station 
acting as secondary can set the ACTPU suppression 
indicator to 0. Therefore, both the primary *and* secondary
link stations can set it to 0. Therefore, *both* link stations
expect to receive ACTPU if the adjacent CP provides SSCP
services.

In addition, I noticed that a discussion of the ODAI bit for 
SSCP-PU sessions has only been introduced in the -3 
architecture referrence. All previous architecture referrences 
simply state that the SIDH = SIDL = 0 for the SSCP PU session, 
as would be expected. The -3 referrence does not discuss ODAI
for SSCP-LU and LU- dependent LU sessions, nor do the previous
referrences.

By omitting a discussion on ODAI for SSCP-PU (and SSCP-LU)
sessions, we could only conclude that the ODAI was used in
exactly the same way as for other session types. We also had
reason to - it was logical: If ACTPU can be requested by both
link stations, there must be a method of distinguishing between
the 2 SSCP-PU sessions that get started (one in each direction).
ODAI is the obvious solution, in the same way that it is used
for other session types.

We already have an implementation that performs the functions
that I have described above. i.e. we both request ACTPU, 
contain dependent LUs, and support the same in adjacent nodes.
We have 2 meaningful sets of session addresses where SIDH is
X'00' and X'01' - one set for each ODAI value.

So I urge the architecture group to reconsider its position on
this matter.

Regards,

Dave

---

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 18 Mar 1994 09:52:00 +0000

In message "Re: AIW 4 APPN Architecture Reference SIG minutes", 

>expect to receive ACTPU if the adjacent CP provides SSCP
...
>X'00' and X'01' - one set for each ODAI value.

Although the importance of support for dependent LUs should decrease in the
future, I feel that this proposal has merit.  I can well understand how
InSession concluded that this capability was part of the architecture, since
the SIDH=00 and 01 values are reserved in BOTH directions.  There is also
clearly no strong reason, other than tradition, for restricting the SSCP-PU
session to a particular direction, especially when, as Dave points out, the
architecture STILL does not explicitly restrict the direction of the
dependent LU sessions themselves.  Since the introduction of the use of ABM
mode on local area networks, the significance of primary and secondary at the
link level is quite obscure.  I glanced briefly through the old SNA
architecture in SC30-3112-2 and could see no explicit dependency on the link
direction.  ACTPU flowed always from primary to secondary link stations
because it flowed from the SSCP to the PU and type 2 PUs were implemented
as secondary link stations in order to keep the manufacturing cost low.

If a node receives an XID from the adjacent link station which has the ACTPU
suppression bit set to 0, and the node has the ability to send an ACTPU, it
should do so, without bothering to look at the polarity of the underlying
link layer.  To be dependent upon the polarity of the link layer is an
unnecessary violation of layering in the protocol.